Skip to main content

BRSKI Flow

sequenceDiagram participant P as Pledge participant R as Registrar participant M as MASA P->>R: iDevID P->>R: Pledge Voucher Request R->>M: Registrar Voucher Request M ->>R: Voucher R->>P: Voucher P->>R: Voucher Status

Using https://nvlpubs.nist.gov/nistpubs/TechnicalNotes/NIST.TN.2123.pdf as a summary

mcr@sandelman.ca is this correct??

High level onboarding policies

In the current NIST builds each has a subtle different policy implicity implemented by the defined flows.

The ambition is to make this more explicit by degree, using explicit evidence

Why this is important: these polices touch on most aspects of IOTSF concerns from assurance to SBOM to vulnerability management etc.

As a sense check we will include an example policy evaluation (and enforcement) point on the standard BRSK flow.

TODO: worth checking for the DPP flows??

Manufacturer approved by network owner​

This is a variation on policy where the owner of the network explicitly enables or disables manufactures. Without this step in place, on boarding flows back to the manufacturer, no matter who they are.

In this model we assume the network owner: is the controller of the CAS and the APs are bound to the CAS.

Or are there other ways of expressing ownership

Implicit options in BRSKI?

sequenceDiagram participant P as Pledge participant R as Registrar participant M as MASA P->>R: iDevID P->>R: Pledge Voucher Request Note right of R: Policy: network owner determines whether manufacturer expected R->>M: Registrar Voucher Request M ->>R: Voucher R->>P: Voucher P->>R: Voucher Status

Device is from manufacturer (no record of instance)​

Test: iDevID is signed by manufacturer

sequenceDiagram participant P as Pledge participant R as Registrar participant M as MASA P->>R: iDevID P->>R: Pledge Voucher Request R->>M: Registrar Voucher Request Note right of M: Policy: MASA validates that manufacture signed M ->>R: Voucher R->>P: Voucher P->>R: Voucher Status

Implicit test in BRSKI?

Device is from manufacturer (with record of instance)​

Test: iDevID is signed by manufacturer

AND MASA has record of specific iDevID

Variations of this can use resesllers or perhaps

Implicit test in BRSKI?

sequenceDiagram participant P as Pledge participant R as Registrar participant M as MASA P->>R: iDevID P->>R: Pledge Voucher Request R->>M: Registrar Voucher RequestA Note right of M: Policy: MASA validates it has record of DeviceID M ->>R: Voucher R->>P: Voucher P->>R: Voucher Status

DeviceID is approved by network owner​

This is a variation on policy where the owner of the network explicitly enables or disables manufactures. Without this step in place, on boarding flows back to the manufacturer, no matter who they are.

In this model we assume the network owner: is the controller of the CAS and the APs are bound to the CAS.

Or are there other ways of expressing ownership

Implicit options in BRSKI?

sequenceDiagram participant P as Pledge participant R as Registrar participant M as MASA P->>R: iDevID Note right of R: Policy: Network owner validates devID is authorised P->>R: Pledge Voucher Request R->>M: Registrar Voucher Request M ->>R: Voucher R->>P: Voucher P->>R: Voucher Status

Device presents attestation voucher approved by manufacturer​

his test assumes some form of secure boot and root of trust.

The attestation voucher will need to be presented upstream

Device instance is certified​

This is a policy where the device is onboard only if this specific device instance has passed a particular test (e.g PAT test). Evidence must be presented to the CAS to demonstrate that the test has passed successfully.

There are many variations of this for different markets

The evidence can be presented by various methods (cloud or device)

Device type is certified​

This is a policy where the device is onboard only if the device type (to which the instance belongs) has passed a test. These could be examples government certificate schemes, consumer schemes etc.

Device behaviour is in network perimeter​

This policy would check the MUD statements attached to the device and ensure that the behaviour matches the expectations of the network

Active vulnerabilities are below threshold​

This policy would check that the vulnerabilities inferred from a device with at threshold determined by the network owner.